2020 年，开发者们希望看到 Rust 发生的事

原文：https://www.parity.io/rust-2020/

翻译：PolkaWorld 社区

在 Parity，我们很早就登上了 Rust 列车。除了一些特定的例外，我们的整个代码库都位于 Rust 中 —— 包括 Parity Ethereum 客户端、Substrate 区块链开发套件和基于 Substrate 的 Polkadot 网络。

我们可能是最大的 Rust 用户之一，并且肯定拥有最大的 Rust 代码库之一，这为我们提供了生态系统中的独特视角。我们有什么理由不用 Rust 来开发？Rust 很棒。

如果没有 Rust 类型的系统、借用检查器和其所提供的工具，我们将无法快速开发新功能和进行区块链实验。Rust 快速的发布周期对我们也很重要。

我们的 Substrate 代码库需要最新的稳定版，因为我们经常在新版本发布的那一天使用最新的稳定版功能合并代码，而且我们许多人实际上是晚上进行开发的。

对所有实现这些快速迭代的人表示敬意！这真是太棒了。尽管有些人可能认为这么快的发布周期会牺牲稳定性或质量，但我们还没有这种经历。

我们也没有经历过导致功能蔓延（注：feature creep，指一产品的功能持续膨胀或增加的情形）或其他常见副作用的经历。恰恰相反：总体而言，我们认为 Rust 正在朝着正确的方向发展。

例如，async/await 虽然对我们的代码库而言并不重要，但它是一个很好的添加，它使代码更具可读性。我们很高兴看到此版本发布，并看到整个 async 故事继续发展。

也就是说，由于我们拥有很大的代码库，我们得以看到一些独特挑战，希望这些问题能引起注意：一些 bug 和语言功能请求、围绕编译器的一些人机工程学和安全性以及总体治理。

.01 Bug 和功能请求

即使是很小的 bug，也可以在庞大的代码库中迅速累积。对我们来说，一个非常棘手的问题是 cargo 的特征泄漏：我们有很多 crates，并且为了使集成测试更容易，我们经常在 dev 依赖项中包含更大的设置，这常常导致烦人的循环依赖项。

同样，我们正在同时为 Wasm 和 native 构建我们的项目（的一部分），但是由于这会通过 std 泄漏，因此我们不得不做一些我们本不愿意做的修改。

同样，从语言的角度来看，Substrate 是一个最通用的区块链开发框架 —— 通用于你使用的加密方式和数据库。通过 Rust 提供的出色特性框架，可以做到这一点。

但是，在这里我们也遇到了一些限制，我们克服了其中许多限制，但我们本希望不必这样。

例如，在 trait 声明中添加 “where” 子句，会迫使我们在想要将类型绑定到该 trait 时复制该 “绑定”。或者我们需要通过代码库复制关联类型上的绑定。

我们相信，大多数这些特质解析问题将通过在 rustc 中切换到 chalk 来解决。我们也热切期待 Rust Specialization。

目前，Substrate 正在使用大量所谓的 “宏魔法（macro-magic）” 来防止用户一次又一次地编写相同的代码。但是，很多用户不满意我们如此依赖宏，因为它隐藏了实际的实现。

我们相信当 Rust 发布 Specialization 时，可以通过大大简化宏来减少宏的使用。

.02 编译器的人机工程学和安全性

除了特定的 bug 和功能，还有一个重要的方面是编译器的人机工程学和安全性。我们认识到并高度赞赏在性能优化和编译时间改进方面所做的工作，但现在，我们不得不采用较差的半吊子解决方案。

现在，有了一个可提取 1000 个 cargo 并超过 160kLOC 的代码库，即便只是在 “野兽”上做很小的更改，就能轻易花掉 8 分钟的编译时间。这头野兽就是我们内部供远程构建的构建服务器，因为它能轻松地让原本性能强大的笔记本电脑硬件花两倍的时间。

即使启用了增量构建和 sccache，每次迭代也很容易发生「写代码-尝试-重复-循环」。其他旨在使开发人员的生活更轻松的工具，比如 Rust 分析器和 RLS 等，在我们的项目中不断受到困扰。

当我们试图让人们使用 Substrate 时，这种情况变得更糟。Substrate 是开发套件。我们必须提供完整的源代码并将其全部构建在用户计算机上，而不是 dylib 或二进制文件，以便他们可以构建其库。

由于 Rust 还不是一个广泛可用的开发环境，因此我们的主要入门教程包含用于设置所有这些内容的脚本 —— 在现代系统上，这个脚本本身需要 45 分钟。

尽管过去的优化主要集中在后续构建上，但是首次设置和构建时间仍然非常长，这成为了人们首次接触 Rust 的痛点。最后，当我们终于让人们完成了安装程序时，他们告诉我们 Rust 很棒，并且正好适合我们要建造的东西。

除了人机工程学之外，安全性对我们来说也至关重要。我们的项目在不受信任的环境中运行去中心化的点对点网络。一个主要功能是允许上述网络的管理机构通过提供新的 Wasm 编译二进制文件来升级其业务逻辑。

我们非常感谢为使合格的编译器继续前进而付出的努力。但是，对于我们的用例而言，更令人关注的是确定性构建。显然，你不能期望每个人都对 Wasm blob 进行内省，并弄清楚它是否按照预期的方式工作。

但是，如果你可以提供源代码，并且当有人使用相同的编译器版本进行构建时，他们会提供与二进制文件完全相同的副本，那么他们可以只查看源代码并信任它。不幸的是，当前情况并非如此，即使对于非 std wasm 也是如此。

我们认为这也可能是解决首次构建问题的一种方案：如果我们具有确定性的构建，则我们可以跨系统共享构建缓存，甚至可以运送预填充的 asset，而不必总是在本地构建 —— 至少对于所有纯 Rust 的东西。

我们很高兴地注意到人们已经恢复了确定性构建的工作，并且我们渴望看到他们在 2020 年的工作成果。

.03 治理：项目和期望管理

对于上面提出的许多问题以及其他问题，我们也很乐意参与进来并提供帮助。毕竟，我们是一家 Rust 公司，我们坚信 Rust 语言、其生态系统和社区，并希望成为其中有价值的参与者。

除此之外，稳定性及其持续进步对我们的业务至关重要。因此，所有对 Rust core、std 及其直接工具的贡献，在 Parity 内部都会获得拥护，即使对于非全职贡献者来说做这些并不容易。

我们有的团队成员也有对帮助专业化或修复上述 bug 感兴趣。但是，有时大家不清楚这项工作是否值得。对于企业而言，很难说一个人可能要花一两个月的时间来开发一项新功能，而不能保证所采用的方法会被接受。

就个人而言，我认为如果一个人用业余时间志愿做的工作被丢掉，只是因为一开始就不能被接受，那可能会更加令人沮丧。

但是，仍然没有明确的途径可以达成正式协议，只有个人保证。但是作为一家倡导透明治理的公司，我们认为必须有更好的方法。

关于这种不清楚的决策过程如何造成损失的一个例子是 async-await 的讨论。尽管最终，这个问题以一种优雅而令人满意的方式得到了解决，但是讨论对参与者造成的情感损失表明，可能会有更好的解决方法。

还有旁观者效应：想到自己可能要面对如此紧张和难搞的人群，贡献者或许会犹豫不决。尤其是，非英语母语者可能不会熟练地捍卫自己的立场，或者贡献者可能没有时间花时间参加讨论。

当然，这是许多志愿者项目共同面临的挑战：随着贡献的增加，交流的增加，在某些时候，所有核心团队似乎正在做的是交流和协调，而这并不是团队所喜欢的。

我们担心看到人们因这个问题和相关问题而离开社区。如果社区烧毁了所有人民，我们就无法建立一个可持续的社区！

你可能想知道我们作为一家公司，如何能够帮助或贡献资源，来解决某些结构性问题和重大问题。这取决于与个人和特定团队进行对话，而不是在公共场合透明地交谈。

Parity 属于分布式、协作式治理企业；我们重视透明度和实用主义。我们不希望任何实体（包括我们）对 Rust 拥有完全控制权，但希望它成为一种参与性、包容性、透明和民主的过程。

我们认为，（大型）公司将在 2020 年显示出更多对参与 Rust 的兴趣。因此，我们担心缺乏正式的参与方式，可能会鼓励公司通过雇用有影响力的人，利用关系 “购买” 治理席位 。

我们高度赞赏合伙人和治理工作组的成立（本文的主要作者之一，在工作之外还兼任了治理工作组成员），并热切希望了解这些工作组的成果以及我们可以怎样帮忙。

总体而言，我们期待着 2020 年的 Rust。我们对 Rust 的热情比以往任何时候都高，并感谢 Rust 社区中的公开讨论。我们绝对确信自己赌对了语言和社区。

更多阅读：▎波卡生态首个稳定币项目Acala测试网Mandala重磅上线！▎Web3 的救赎：区块链可扩展性与互操作性
▎30岁的 Web 崩坏了，但Web3.0革命正在进行

扫码关注公众号，回复“1”加入开发者社群